Size Change: +141 B (0%)

Total Size: 1.07 MB

_{compressed-size-action}

Changed the default from a pipe (|) to a comma (, ) since that is what most themes use for lists of terms like categories and tags.

This works great in my testing.

The only thing I'm not sure about is whether this needs to live in the Advanced section — since this block doesn't have very many controls to begin with, I think it might as well be highlighted elsewhere in the sidebar. Adding Needs Design Feedback for a second opinion on that.

This reminds me a lot of #23293

The designs in that issue all seemed to default to showing this option in the sidebar and also included a spacing and size option — all under it's own accordion section:

--

I think it could make sense to expose something like this in a block's toolbar, and the post-terms block is a good example. There are minimal controls in the toolbar already, and controlling the separators feels important enough to the block's needs to show in the toolbar. With that in mind, I wonder if there's a way to have one UI that will work both in the sidebar and in the toolbar.

I wonder if there's a way to have one UI that will work both in the sidebar and in the toolbar.

Something like this will be needed.

It's not clear to me what the suggested design is though? @shaunandrews is this the design suggested to be explored but in the toolbar?

If yes, even though it might be something toolbar worthy, I think that 3 rows of controls would hide the contents, making the preview of what changes are applied more difficult, no?

"Spacing" makes sense, but I would skip "size" to keep things more straightforward. I don't think this belongs in the toolbar.

I guess this PR needs the spacing control as well, no? With the spacing control we should remove the extra space from the default value , as this is not visible in the input and might lead to some confusion there.

There's nothing stopping us from adding spacing controls in future iterations, but I'm unsure whether that would be a requirement or not for a 1st iteration. The "separator characters(s)" control would always be needed regardless of whether we have spacing or not, so IMO it would be safer to go with something small and if we see that spacing is required and requested, then add it.

Personal opinion: I was thinking that the spacing control would probably add too much complexity for something that may not necessarily need that much... The space character may not be directly visible when editing the block, but when entering the control and actually editing the value, it becomes self-evident and is extremely simple to use. Granted, it's not perfect, but maybe it's the lesser of 2 evils? As a user I'd rather hit the spacebar once or twice than have to edit a bunch of separate controls 😅

Yeah — assuming we stick with the comma as a default separator, I think a spacing control is unnecessary for this iteration.

Okay then, let's land this first iteration as is, but first we should add a style to the separator to preserve white-space like:

span.wp-block-post-terms__sep {
    white-space: pre-wrap;
}

Since JSX removes whitespace. You can try this by just adding more than one space in separator.

Okay then, let's land this first iteration as is, but first we should add a style to the separator to preserve white-space like:

span.wp-block-post-terms__sep {
    white-space: pre-wrap;
}

Since JSX removes whitespace. You can try this by just adding more than one space in separator.

Great catch! Done in e5c8fb8 👍